Skip to content

feat: improve readme loading and error handling#1380

Draft
essenmitsosse wants to merge 4 commits intonpmx-dev:mainfrom
essenmitsosse:improve-readme-loading
Draft

feat: improve readme loading and error handling#1380
essenmitsosse wants to merge 4 commits intonpmx-dev:mainfrom
essenmitsosse:improve-readme-loading

Conversation

@essenmitsosse
Copy link
Contributor

For now a little experimental, what to do some exploration and see if this could be a direction we can/should be going.

  1. Extract Readme component from package page
    This has the benefit of better separation of concerns. The data loading is also moved into the component. Since the Playground component needs the same data, both now do a fetch, but that gets deduplicated.
  2. Add explicit loading and error state for Readme
    This mainly fixes the issue of "There is no Readme appearing" when something goes wrong

As it is currently implemented I am not sure in which cases the loading state for the Readme would appear. We could load it non-blocking which would render the rest of the page faster so it can load in the background. I am not sure exactly though what the best way to do this in Nuxt is.

I think ideally the whole page should be rendered via SSR, if all the fetches have cached results. Otherwise a component like the readme component could be client side rendered to have faster time to interaction.

This pattern would also allow us to control the loading skeletons on a per component basis, while making it easier to already show headings etc.

If we would follow through with this the whole page could be small components, each fetching their own data, with Nuxt deduplication making sure we fetch the same thing twice. I have worked with a similar pattern in Next and I really liked it from a DX as well as from a UX perspective (because it makes it easier to show each thing as early as possible, without being blocked by other data that might be needed elsewhere).

Open questions

  • SWR. Currently you might see an outdated version of the readme, but it looks ready and then might change after a moment to the current version. Is that what we want? Shouldn't there at least be some indication that it's still refreshing?
  • I think someone mentioned that caching happens only for explicit version, but most package views will come from non-explicit version, so they will always have to get the correct version first?
  • There might also be some problem with the current setup and changes to be made, because I am not sure, if this way the Readme will start to fetch it's data before the main package page is ready.

@vercel
Copy link

vercel bot commented Feb 11, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
npmx.dev Ready Ready Preview, Comment Feb 11, 2026 0:19am
2 Skipped Deployments
Project Deployment Actions Updated (UTC)
docs.npmx.dev Ignored Ignored Preview Feb 11, 2026 0:19am
npmx-lunaria Ignored Ignored Feb 11, 2026 0:19am

Request Review

@github-actions
Copy link

Lunaria Status Overview

🌕 This pull request will trigger status changes.

Learn more

By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.

You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

File Note
lunaria/files/en-GB.json Localization changed, will be marked as complete.
lunaria/files/en-US.json Source changed, localizations will be marked as outdated.
Warnings reference
Icon Description
🔄️ The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.

@essenmitsosse essenmitsosse changed the title Improve readme loading and error handling feat: improve readme loading and error handling Feb 11, 2026
@essenmitsosse
Copy link
Contributor Author

Alternative approach would be to still load all the data in the main page component, but pass the fetch response object (including status and error) to the components to handle those correctly. This wouldn't change much about the data fetching, but would still allow for more granular loading state and error handling. Would also allow to test the loading state per component.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant